C.S.M.P. Digest Sat, 10 Oct 92 Volume 1 : Issue 181 Today's Topics: How do I mount a SCSI device? Hermes external in C Creating background tasks (HELP!). How to increase stack size ??? The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly. The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. (This means you can't post questions to the digest.) Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at cs.uoregon.edu). Article threads are not added to the digest until the last article added to the thread is at least one month old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu [128.223.8.8] in the directory /pub/mac/csmp-digest. Be sure to read the file /pub/mac/csmp-digest/README before downloading any files. The most recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the directory /info-mac/digest/csmp. If you don't have ftp capability, the sumex archive has a mail server; send a message with the text '$MACarch help' (no quotes) to LISTSERV@ricevm1.rice.edu for more information. The digest is also available via email. Just send a note saying that you want to be on the digest mailing list to mkelly@cs.uoregon.edu, and you will automatically receive each new issue as it is created. Sorry, back issues are not available through the mailing list. Send administrative mail to mkelly@cs.uoregon.edu. ------------------------------------------------------- From: triantos@acsu.buffalo.edu (Nick B Triantos) Subject: How do I mount a SCSI device? Date: 31 Aug 92 15:22:42 GMT Organization: The University at Buffalo Hi, Forgive me if this is in the FAQ, but I couldn't find it. I'd like to write a program for myself that, when launched, will simply mount all SCSI devices it finds in the chain. I've looked in IM for a magic SCSIMount function, or something reasonably close, and I can't find anything which I can understand. Please post any suggestions you might have, or pointers to code which may help me. Thanks much, - -Nick - -- Nick Triantos internet: triantos@acsu.buffalo.edu AOL: Triantos "Scientists tell us that the fastest animal on earth, with a top speed of 120 ft/sec, is a cow that has been dropped out of a helicopter." - Dave Barry +++++++++++++++++++++++++++ From: zobkiw@world.std.com (Joe Zobkiw) Date: 31 Aug 92 17:02:01 GMT Organization: The World Public Access UNIX, Brookline, MA In article triantos@acsu.buffalo.edu (Nick B Triantos) writes: >Hi, > >Forgive me if this is in the FAQ, but I couldn't find it. I'd like to write a >program for myself that, when launched, will simply mount all SCSI devices it >finds in the chain. I've looked in IM for a magic SCSIMount function, or >something reasonably close, and I can't find anything which I can understand. >Please post any suggestions you might have, or pointers to code which may help >me. > Look at the low-level File Manager calls such as PBMountVol...I think this is what you want. - -- - ------------------------------------------------------------- joe zobkiw zobkiw@world.std.com aol: aflzobkiw +++++++++++++++++++++++++++ From: maarten@fwi.uva.nl (Maarten Carels) Date: 1 Sep 92 09:17:26 GMT Organization: FWI, University of Amsterdam zobkiw@world.std.com (Joe Zobkiw) writes: >In article triantos@acsu.buffalo.edu (Nick B Triantos) writes: >>Hi, >>Forgive me if this is in the FAQ, but I couldn't find it. I'd like to write a >>program for myself that, when launched, will simply mount all SCSI devices it >>finds in the chain. I've looked in IM for a magic SCSIMount function, or >>something reasonably close, and I can't find anything which I can understand. >Look at the low-level File Manager calls such as PBMountVol...I think this >is what you want. Guess not. There is much more to do for SCSI devices. You have to: - - determine it's there. Try to read block 0 from the device (you'll need it anyway). If you can't read the block, assume no device present. - - using block 0, locate the driver on the disk, allocate memory in the system heap, read the driver, and jsr to it with some parameters in registers. - - the driver should post a disk inserted event for any partition it wants to be mounted. Process all disk inserted events. Documentation for all of this? Inside Mac volume IV and V (SCSI manager, scsi disk layout) some technotes SCSI Development package (APDA, way out of date, but it some things are only documented in comments in the example driver). Are you sure you want to make such beastie? SCSI hacking on macintoshes is fun, but it's not easy (I know, I made disk drivers). - --maarten - -- In real life: Maarten Carels Computer Science Department University of Amsterdam email: maarten@fwi.uva.nl +++++++++++++++++++++++++++ From: bwilliam@iat.holonet.net (Bill Williams) Date: 7 Sep 92 09:39:41 GMT Organization: HoloNet (BBS: 510-704-1058) >>mount all SCSI devices it finds in the chain..... Do not write a mounting program unless you do it correctly. To do it correctly is too much work. I'll demonstrate: Steps include 1: Finding all devices on the bus that are FIXED STORAGE, OPTICAL, and CD-ROM while ignoring things like Voice Navigators and Scanners. Requires knowledge of the SCSI Manager. 2: Unmounting all currently existing unmountable volumes supported by the existing drivers for safety (plus you won't be able to unmount the system volume or the current app volume) 3: Finding the first VALID HFS SCSI driver form the devices from the DDM Driver Descriptor Map, in Block0 structure of disk (first block) Plus reading just the first 512 bytes of the SCSI Block even if its logical block size is larger than 512 bytes. Then via block zero you can deduce which of several Partition map entries in the PARTITION MAP partition is the desired driver. Then you need to officially validate the checksum found in the partition map entry describing the driver you are seeking via IM 5 if the partition map name begins with 'MACI' in upper OR lower case 4: once found you need to load the driver into memory and check its memory against its checksum for safety. Also you need to load it into a non relocatable area of the system heap, and GUARANTEE THAT THE SYSTEM HEAP CAN AFFORD to accept a further loss of space (if not in System 7 with expandable system 7 heaps). Size of driver is stored in partition map entry but be careful not to multiply the logical block size (its units) by the "ddSize" of the DDM since Apple structures are all internally stored using 512 byte logical blocks. 5: once the driver is ready and found, you need to jumpstart the driver as if it was being called by the normal bootup processes of the Mac after ILLEGALLY TAKING OVER THE CURRENT SCSI SLOT SPACE in the driver for that device using Apples official current regular (non "Cousin It") guidlines: (unit_Table_Ptr = (DCtlHandle *)UTableBase; unit_Table_Ptr += 32 + device_ID;/* Point at SCSI ID direct slot */) void Mount_SCSI_Drive(long scsi_Address, Ptr driver_Start) { asm { movem.l d0-d7/a0-a6,-(sp) suba.l a0,a0 moveq.l #0,d7 move.l scsi_Address,d5 bset.l #31,d5 ;To indicate not being called at boot time move.l driver_Start,a1 jsr (a1) movem.l (sp)+,d0-d7/a0-a6 } /* asm */ } /* pascal void Mount_SCSI_Device(INTEGER_32 scsi_Address... */ 6: The Driver, not you,has the duty of cycling through partition entries so Thats all there is. Thats it. They will mount. Problems with ANY technique such as mounting like this include: Having drivers ORPANED IN MEMORY! This is because no SCSI drivers currently have to support a "Close" command and WILL BE ORPAHANED. They may be may be doing evil background tasks, VBL tasks, or have nasty shutdown manager calls installed. Taking over a SCSI Slot space is naughty. Conclusion: DO NOT WRITE a "SCSI Probe", nor use SCSI Probe. However the steps just listed in this article are all properly done in the "SCSI Director* Assistant 1.5.1" CDEV that has various names and was available from 18 different companies including APS,Club Mac,VCP, etc etc. PS "SCSI Probe 3.x" violates most rules and does things such as mounting OFFLINE devices that are OFFLINE and not Normal Device Queue Entries (such as RAM Disks that are closed down with raw memory addresses in the entry, MS-DOS volumes, etc. KaBOOM. BWilliams (If you need to speak to me use EMail since I never usually read Mac oriented usenet stuff... but I may start) +++++++++++++++++++++++++++ From: bwilliam@iat.holonet.net (Bill Williams) Organization: HoloNet (BBS: 510-704-1058) Date: Mon, 7 Sep 1992 08:32:26 GMT --------------------------- From: Mary.Hicks@p0.f222.n125.z1.FIDONET.ORG (Mary Hicks) Subject: Hermes external in C Date: 29 Aug 92 21:45:18 GMT Organization: FidoNet node 1:125/222.0 - Macademe/Emma, San Francisco CA I would like to make an external for hermes, just as an example, but I dont understand how. I read the Hermes Interface file, but I still need help. I currently know how to program in C, but I cant make an external. How would I compile this into an external.\] main() { printf(" This is an example of a dumb external!"); } - -------------------------------------------------- Well thats it. I also have the hermes headers fie in 'C', but how do I compile the above code into an external? Please give step by step info. thanks, Mary Hicks - -- Mary Hicks - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!222.0!Mary.Hicks INTERNET: Mary.Hicks@p0.f222.n125.z1.FIDONET.ORG +++++++++++++++++++++++++++ From: zaphod@bluemoon.rn.com (Peter Bierman) Organization: Blue Moon BBS ((614) 868-998[024]) Date: Tue, 01 Sep 92 00:07:35 EDT Mary.Hicks@p0.f222.n125.z1.FIDONET.ORG (Mary Hicks) writes: > I would like to make an external for hermes, just as an example, but I > dont understand how. I read the Hermes Interface file, but I still need > help. I currently know how to program in C, but I cant make an external. Well, first, get the HermHeaders in Pascal. The HEI file has some examples, namely the phone external, that pretty much does what you asked. The basic idea is that your external keeps a block in the heap with variables. When you get called, you check a variable to see where you were in your external, then you do a BIG case statement to get there. When you finish one "stage" you update the stage variable to the next part of the external to be called, and then go back to Hermes. Hermes should then do some stuff, and call you again, and the cycle goes on. It's pretty simple actually, just takes a little getting used to. Partly because for a Mac programer, it's wierd to work in modes. - --- The opinions I express are rarely my own, because my own are far too outragous to post here. IntNet:zaphod@bluemoon.rn.com FutureNet: #33@#10 The Metropolis (614)-846-1911 - --- +++++++++++++++++++++++++++ From: Glen.Stewart@f175.n2240.z1.ieee.org (Glen Stewart) Date: 31 Aug 92 14:21:01 GMT Organization: FidoNet node 1:2240/175 - The Associati, Grand Blanc MI Mary - You're pretty ambitious. First I read you're looking for Basic source, now C tips for Hermes... I'm just completing a Think C project which is a very functional Hermes external. It's almost fully commented, and the program flow is pretty understandable. I'm no pro, but I've picked up that the standard printing command is not acceptable to Hermes - it wants control of everything like that. So there are some special functions you can call that will take care of this for you. I'm struggling to fix a problem from the modification I made to the original program, by Robert Duran Jr. Once it is fixed (I'll be working on it this afternoon, I hope), I'll put it online on my BBS and on the Hermes support BBS. The more basic functions are really easy to implement (simple textual interaction), but anything calling the idle loop (hooks into the main interface) are tricky and poorly documented. I'm also trying to update the HermesHeader.h to Hermes 2.0 status. This update is also nearly complete - trying to get a little help from Robert on this one. Bye for now. - -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Glen Stewart - Internet: Glen.Stewart@f175.n2240.z1.ieee.org --------------------------- From: baer@qiclab.scn.rain.com (Ken Baer) Subject: Creating background tasks (HELP!). Date: 13 Aug 92 17:00:29 GMT Organization: SCN Research/Qic Laboratories of Tigard, Oregon. OK, first of all, I do realize that the Mac OS does not yet support real Multitasking (nor does MS Windows). But, I keep hearing about certain applications or inits that allow programs to run in the background (like the one that allows Think C to compile in the background). What I want to do is allow our 3D rendering software to render in the background to the user can use the modeller etc. while rendering. Could someone either post, or point me to some documented code to set this up? What are the limits and conditions to this? We are already doing this under Windows, so I imagine a similar process should be possible on the Mac. Any and all related information will be greatly appreciated. -Ken Baer. baer@qiclab.scn.rain.com - -- // -Ken Baer. Programmer/Animator, Hash Enterprises \X/ Usenet: baer@qiclab.UUCP / Office: (206)573-9427 "Hey, I think a glacier just passed us!" - Andy from Joyride +++++++++++++++++++++++++++ From: kent@sunfs3.Camex.COM (Kent Borg) Date: 14 Aug 92 00:05:35 GMT Organization: Camex Inc., Boston MA In article <1992Aug13.170029.3055@qiclab.scn.rain.com> baer@qiclab.scn.rain.com (Ken Baer) writes: >OK, first of all, I do realize that the Mac OS does not yet support real >Multitasking (nor does MS Windows). Careful, thousands of people are cringing right now over the flame war you might have just touched off. (Some people are so irresponsible.) >But, I keep hearing about certain applications or inits that allow >programs to run in the background (like the one that allows Think C >to compile in the background). It is pretty easy for an application to do. In fact, it is so easy that INITs have been known to convince certain applications to do it. (To be honest, I am pretty sure Think C has always allowed some background processing, it just kept the user tied up while this went on.) >What I want to do is allow our 3D rendering software to render in the >background to the user can use the modeller etc. while rendering. >Could someone either post, or point me to some documented code to set >this up? Look in Inside Macintosh Volume VI or the new "Processes" volume of Inside Macintosh for details, but in general, there are two things to do: 1) When your code gets CPU time (you will know this because it is executing) do your thing. 2) When the user decides to say something to your running code--for example canceling the rendering he mistakenly started--notice the "Stop" menu choice, or "Cancel" button, or command-period keystroke, and act on it (by stopping in this case). Because this is a user-oriented machine which is valuable precisely for its user interface, be very responsive about noticing that the user is talking to you. Don't make the user pound on the keyboard. To notice that the user is talking, call GetNextEvent(), and act on anything you hear. (Or call WaitNextEvent() if you are just sitting around waiting for something to happen.) Oh, and don't do anyThink stupid like putting up a traditional modal dialog box. It will prevent the user from switching to another layer. Use a regular window or a newer movable modal dialog instead. Simple. You are done. You have written a program which is responsive to the user and it is happily multitasking. Okay, this does mean that inside your tight loops you need to notice the passage of time and occasionally check for user input. (Do this several times a second--and possibly be clever and calibrate this at runtime based on how fast my Mac can run your loop.) But what do you expect of an 8-plus-year-old architecture which started out in 128K of unprotected RAM?? Don't get greedy. The secret: Everytime you call GetNextEvent() or WaitNextEvent() the system potentially offers execute time to other applications. Everytime the other applications call one of those routines you potentially get execute time. Coopertive multitasking does require cooperation but it makes for a very user-responsive system when folks do cooperate. It is what Modern True Real Time Multitasking Operating Systems very often do--honest. Make Sense? If not, say so and there will be lots of helpful advice coming your way--but PLEASE avoid fighting words like "Real Multitasking" in future postings. - -- Kent Borg kent@camex.com or kentborg@aol.com H:(617) 776-6899 W:(617) 426-3577 As always, things look better when some costs are left out. -Economist 3-28-92 p. 94 +++++++++++++++++++++++++++ From: mcmath@csb1.nlm.nih.gov (Chuck McMath) Date: 14 Aug 92 12:32:58 GMT Organization: MSD In article <1992Aug13.170029.3055@qiclab.scn.rain.com>, baer@qiclab.scn.rain.com (Ken Baer) wrote: > > OK, first of all, I do realize that the Mac OS does not yet support real > Multitasking (nor does MS Windows). But, I keep hearing about certain > applications or inits that allow programs to run in the background (like > the one that allows Think C to compile in the background). What I want > to do is allow our 3D rendering software to render in the background to > the user can use the modeller etc. while rendering. Could someone either > post, or point me to some documented code to set this up? What are the > limits and conditions to this? We are already doing this under Windows, > so I imagine a similar process should be possible on the Mac. > > Any and all related information will be greatly appreciated. Well, what you're really seeing is applications that can do tasks in the background. When the front application doesn't have pending events and it calls WaitNextEvent background applications get time - that is, if the frontmost application is well-behaved (please, gurus, correct me if I misspeak!) What you want to to is bone up (i.e., read Inside Mac) on the Event Manager (maybe?) and see how applications that are not in the foreground get time. Then you need to structure your rendering task so it can be done in small chunks, because it would not be polite for a background task to grab the computer and not let go (cf PrintMonitor!). Once you set up your renderer this way, it needs to be on the lookout for those events that apps get when they're in the background, and do some rendering then. It's easy to talk about, but, I believe, difficult to achieve in practice! chuck |- chuck mcmath - mcmath@csb1.nlm.nih.gov - MSD, Inc. ------------| |- National Library of Medicine - National Institutes of Health --| |- Bethesda, MD 20894 - !aixelsyd evah uoy siht daer nac uoy fI -| |- "Hey batter, hey batter, hey batter, swing" - Anon. -----------| +++++++++++++++++++++++++++ From: jstevens@crick.ssctr.bcm.tmc.edu (Jason Philip Stevens) Date: 14 Aug 1992 15:21:17 GMT Organization: Baylor College of Medicine, Houston, Tx In article <1992Aug13.200535.18236@sunfs3.Camex.COM>, kent@sunfs3.Camex.COM (Kent Borg) writes: |> In article <1992Aug13.170029.3055@qiclab.scn.rain.com> baer@qiclab.scn.rain.com (Ken Baer) writes: |> >What I want to do is allow our 3D rendering software to render in the |> >background to the user can use the modeller etc. while rendering. |> >Could someone either post, or point me to some documented code to set |> >this up? |> |> Look in Inside Macintosh Volume VI or the new "Processes" volume of |> Inside Macintosh for details, but in general, there are two things to |> do: |> |> 1) When your code gets CPU time (you will know this because it is |> executing) do your thing. |> |> 2) When the user decides to say something to your running code--for |> example canceling the rendering he mistakenly started--notice the |> "Stop" menu choice, or "Cancel" button, or command-period keystroke, |> and act on it (by stopping in this case). Another option that may be more in line with what you really want to do is use threads. The new Threads package from apple allows programs to have multiple threads of execution. In your case, a single program (not seperate processes, as described above) could well shunt off all of the compute intensive rendering into a new thread, that would chug along while the user was free to interact with the rest of the program (which resides in its own thread). - -jps - -- Jason Stevens Internet: jstevens@bcm.tmc.edu Network User Services Voice: (713) 798-7370 Baylor College of Medicine Opinions expressed are mine alone. +++++++++++++++++++++++++++ From: scott@mcl.ucsb.edu (Scott Bronson) Date: 24 Aug 92 00:50:37 GMT In <1992Aug13.200535.18236@sunfs3.Camex.COM> kent@sunfs3.Camex.COM (Kent Borg) writes: >In article <1992Aug13.170029.3055@qiclab.scn.rain.com> baer@qiclab.scn.rain.com (Ken Baer) writes: >>What I want to do is allow our 3D rendering software to render in the >>background to the user can use the modeller etc. while rendering. >>Could someone either post, or point me to some documented code to set >>this up? >1) When your code gets CPU time (you will know this because it is >executing) do your thing. >2) When the user decides to say something to your running code--for >example canceling the rendering he mistakenly started--notice the >"Stop" menu choice, or "Cancel" button, or command-period keystroke, >and act on it (by stopping in this case). 3) Set the "accept background null events" in your size resource or you'll wait a really long time for your code to finish if you switch it to the background... I forget to do this way too often. >Because this is a user-oriented machine which is valuable precisely >for its user interface, be very responsive about noticing that the >user is talking to you. Don't make the user pound on the keyboard. Er, technically speaking the user cannot interact with your program while it is in the background. He/she/it must switch it to the foreground to cancel the rendering. I assume your renderer already allows cancel, so no changes here. I believe the only two events you get while you are backgrounding are nullEvt and updateEvt and an OS activate event when you get switched back forward. (I think...) Pass very small values to the sleepTime parameter in WaitNextEvent (don't use GetNextEvent unless you HAVE to), and when you get time, take a tick or two and get a few more calculations again. Then call WaitNextEvent so that other processes can get their fair time. You can use the following loop so that you can get the processor for a fair amount of time: // Uncompiled C code from memory below -- use at own // risk, but you get the idea. long l; EventRecord e; while( task not done ) { if( WaitNextEvent( everyEvent, &e, 0L, nil ) ) { HandleUpdateOrOSEvent(); } else { l = Ticks + 2; do { SmallIncrementalPartOfYourTask() } while( Ticks < l ); } } Note that if you want to be future compatible, use TickCount() instead of the low memory global Ticks. I use TickCount() because I figure that if Ticks ever fails, it will be trivial to re-compile using TickCount(). However, none of the apps I've developed have been commercial (so far) so I haven't had to worry about expensive upgrades. This is how I've been doing it. If anyone has any suggestions, please do tell. - Scott +++++++++++++++++++++++++++ From: kent@sunfs3.Camex.COM (Kent Borg) Date: 24 Aug 92 17:34:40 GMT Organization: Camex Inc., Boston MA In article scott@mcl.ucsb.edu (Scott Bronson) writes: >(don't use GetNextEvent unless you HAVE to) Quite right. My posting was wrong. I though that WaitNextEvent() reduced to the same thing as GetNextEvent() when the wait was zero and the rgn empty. Wrong. WaitNextEvent() also calls SystemTask() for you--and possibly other differences I am still forgetting. I knew this and forgot it and got burned by it just last week. Bottom line: Only use GetNextEvent() when WaitNextEvent() doesn't exist (on old systems, for example). - -- Kent Borg kent@camex.com or kentborg@aol.com H:(617) 776-6899 W:(617) 426-3577 As always, things look better when some costs are left out. -Economist 3-28-92 p. 94 +++++++++++++++++++++++++++ From: joshr@kronos.arc.nasa.gov (Joshua Rabinowitz-Summer-91) Date: 24 Aug 92 23:49:02 GMT Organization: NASA/ARC Information Sciences Division In article <1992Aug24.133440.1050@sunfs3.Camex.COM> kent@sunfs3.Camex.COM (Kent Borg) writes: >In article scott@mcl.ucsb.edu (Scott Bronson) writes: >>(don't use GetNextEvent unless you HAVE to) > >Quite right. My posting was wrong. I though that WaitNextEvent() >reduced to the same thing as GetNextEvent() when the wait was zero and >the rgn empty. Wrong. WaitNextEvent() also calls SystemTask() for ^^^^^^^^^^^^^^^^^^ No. WaitNextEvent() does NOT call systemTask() -- it has it's own way of dealing with this type of action for you. But it does not, to the best of my knowledge, call SystemTask(), which should not be used (does nothing?) under systems with WaitNextEvent(). >you--and possibly other differences I am still forgetting. I knew >this and forgot it and got burned by it just last week. Not trying to flame. > >Bottom line: Only use GetNextEvent() when WaitNextEvent() doesn't >exist (on old systems, for example). YES. > >-- >Kent Borg kent@camex.com or kentborg@aol.com > H:(617) 776-6899 W:(617) 426-3577 >As always, things look better when some costs are left out. > -Economist 3-28-92 p. 94 - -- - ---------------------------------- #include Josh Rabinowitz, Mac TCL programmer joshr@kronos.arc.nasa.gov "Send a salami to your boy in the army" - Katz's delicatessen, NYC +++++++++++++++++++++++++++ From: urlichs@smurf.sub.org (Matthias Urlichs) Date: 8 Sep 92 15:17:51 GMT Organization: University of Karlsruhe, FRG In comp.sys.mac.programmer, article <1992Aug24.234902.26204@kronos.arc.nasa.gov>, joshr@kronos.arc.nasa.gov (Joshua Rabinowitz-Summer-91) writes: > In article <1992Aug24.133440.1050@sunfs3.Camex.COM> kent@sunfs3.Camex.COM (Kent Borg) writes: > >In article scott@mcl.ucsb.edu (Scott Bronson) writes: > >>(don't use GetNextEvent unless you HAVE to) > > > >Quite right. My posting was wrong. I though that WaitNextEvent() > >reduced to the same thing as GetNextEvent() when the wait was zero and > >the rgn empty. Wrong. WaitNextEvent() also calls SystemTask() for > ^^^^^^^^^^^^^^^^^^ > > No. WaitNextEvent() does NOT call systemTask() -- it has its own > way of dealing with this type of action for you. But it does not, > to the best of my knowledge, call SystemTask(), which should not be used > (does nothing?) under systems with WaitNextEvent(). WaitNextEvent calls GetNextEvent when the wait is zero and the region empty. GetNextEvent calls SystemTask internally. (This is under System 7.0.1. Set a BReak on WaitNextEvent, Go, set a BReak on SystemTask, Go, StackCrawl, examine code at calling points. Clear breakpoints, Go. All this is Macsbug; your debugger may vary. :-) All three routines are reimplemented by System 7. Given this, calling SystemTask is superfluous but definitely harmless. - -- "For that matter, compare your pocket computer with the massive jobs of a thousand years ago. Why not, then, the last step of doing away with computers altogether?" -- Jehan Shuman - -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/ --------------------------- From: tschneid@uwovax.uwo.ca Subject: How to increase stack size ??? Organization: University of Western Ont, London Date: Tue, 1 Sep 1992 18:56:11 GMT I am working on a port of Gunplot 3.2 to the Mac. So far I have most of the basics working (only a few bugs left) ... however, I keep running out of stack space. I did some reading and found out that the Mac only provides 8k of stack space and that it can be changed by doing something like (in VERY rough C pseudo-code) THz newapplimit; newapplimit = 300*1024; /* give app 300k */ SetApplLimit(ApplLimit()+newapplimit); MaxApplLimit(); Unfortunately, this does not work ... Can anyone enlighten me? I would like to set up a fixed stack size of 32k (i.e. not dependent on the memory allotted by the user in the applications info box). I am using Think C 5.02. Thanks, Todd Schneider +++++++++++++++++++++++++++ From: damurphy@wc.novell.com (Duane A Murphy) Date: 2 Sep 92 15:48:22 GMT Organization: Novell, Inc. - Walnut Creek In article <1992Sep1.145611.1@uwovax.uwo.ca> tschneid@uwovax.uwo.ca writes: > >I am working on a port of Gunplot 3.2 to the Mac. So far I have most >of the basics working (only a few bugs left) ... however, I keep >running out of stack space. I did some reading and found out that the >Mac only provides 8k of stack space and that it can be changed by doing >something like (in VERY rough C pseudo-code) > > THz newapplimit; > > newapplimit = 300*1024; /* give app 300k */ > SetApplLimit(ApplLimit()+newapplimit); > MaxApplLimit(); > >Unfortunately, this does not work ... > >Can anyone enlighten me? I would like to set up a fixed stack size of >32k (i.e. not dependent on the memory allotted by the user in the >applications info box). I am using Think C 5.02. > >Thanks, >Todd Schneider I also ran into a stack limitation problem. Actually the stack is handled differently on different machines. It is not consistent. "Small" machines have an 8K stack. "Large" machines have a 24K stack. There is a low memory global "DefltStack" that determines the stack size at startup. Dont mess with this, it affects everyone. After a few days of trying to figure out how the stack space is managed; that is what pointers in the heap kept track of the stack to detect a stack heap collision, we came up with the following very simple solution. #define STACK_MIN 0x8000L pascal Ptr StackPtr(void) = {0x2e8f}; /* MOVE A7, (A7) */ int main(void) { SetApplLimit(StackPtr() - STACK_MIN); ... The StackPtr() function came from the net (thanks to whomever suggested this). The stack has no direct pointers to set its limits. It is actuall controlled by heap limit pointers, namely ApplLimit. This moves ApplLimit the where the current stack is at down the size of the stack that you want. Hope this helps, ...Duane Murphy Novell, Walnut Creek +++++++++++++++++++++++++++ From: grobbins@Apple.COM (Grobbins) Date: 2 Sep 92 18:55:00 GMT Organization: Apple Computer Inc., Cupertino, CA In article <1992Sep2.154822.12924@novell.com> damurphy@wc.novell.com (Duane A Murphy) writes: >In article <1992Sep1.145611.1@uwovax.uwo.ca> tschneid@uwovax.uwo.ca writes: >>...I keep running out of stack space. > >I also ran into a stack limitation problem. Actually the stack is handled >differently on different machines. It is not consistent. "Small" machines >have an 8K stack. "Large" machines have a 24K stack. There is a low memory >global "DefltStack" that determines the stack size at startup. Dont mess >with this, it affects everyone. Color QuickDraw machines do have a 24K default stack. Be aware that the Process Manager always increases the partition size by (default stack - 8K) when launching applications, so the extra 16K stack space on Color QuickDraw machines does not reduce the heap size under what would be available on a 68000 machine (but the app's partition is 16K larger than the partition size set by the programmer.) >pascal Ptr StackPtr(void) = {0x2e8f}; /* MOVE A7, (A7) */ >... > SetApplLimit(StackPtr() - STACK_MIN); This is a bit more 680x0 dependent than source code should be these days. Here's a function which uses documented calls to increase the stack size. // Increase the space allocated for the application stack // // Warning: SetApplLimit always sets the stack to at least as large as the // default stack for the machine (8K on machines with original QuickDraw, // 24K on machines with Color QuickDraw) so the application partition // must be large enough to accomodate an appropriate stack and heap OSErr IncreaseApplicationStack(Size incrementSize) { OSErr retCode; // increase the stack size by lowering the heap limit SetApplLimit((Ptr) ((unsigned long) GetApplLimit() - incrementSize)); retCode = MemError(); if (retCode == noErr) MaxApplZone(); return retCode; } Do heed the warning given in the comment. All stack allocation beyond the default must be compensated for by increasing the partition size in the SIZE -1 resource. This is particularly an issue for faceless background apps, which have a default stack size of only 2K. SetApplLimit will grow an FBA's stack to at least 24K on Color QuickDraw machines, so the partition size should be larger than that. Grobbins grobbins@apple.com Usual disclaimers apply. +++++++++++++++++++++++++++ From: ksand@apple.com (Kent Sandvik) Date: 2 Sep 92 00:31:07 GMT Organization: Apple In article <1992Sep1.145611.1@uwovax.uwo.ca>, tschneid@uwovax.uwo.ca wrote: > > > I am working on a port of Gunplot 3.2 to the Mac. So far I have most > of the basics working (only a few bugs left) ... however, I keep > running out of stack space. I did some reading and found out that the > Mac only provides 8k of stack space and that it can be changed by doing > something like (in VERY rough C pseudo-code) MacII ROMs: 24k Old Macs (Plus, SEs): 8k Color QuickDraw systems: 24k MacApp applications (24k by default). > > THz newapplimit; > > newapplimit = 300*1024; /* give app 300k */ > SetApplLimit(ApplLimit()+newapplimit); > MaxApplLimit(); > > Unfortunately, this does not work ... In what way, collision of stack and heap (more memory required then)? Other problems? Kent Sandvik/DTS +++++++++++++++++++++++++++ From: buckeye@spf.trw.com (John Wallace) Date: 2 Sep 92 20:23:29 GMT Organization: TRW Sensor Data Processing Center, Redondo Beach, CA In article <1992Sep2.154822.12924@novell.com> damurphy@wc.novell.com (Duane A Murphy) writes: >In article <1992Sep1.145611.1@uwovax.uwo.ca> tschneid@uwovax.uwo.ca writes: >> >>I keep running out of stack space. >>Todd Schneider > >I also ran into a stack limitation problem. Actually the stack is handled >differently on different machines. It is not consistent. "Small" machines >have an 8K stack. "Large" machines have a 24K stack. > >#define STACK_MIN 0x8000L >pascal Ptr StackPtr(void) = {0x2e8f}; /* MOVE A7, (A7) */ > >int main(void) >{ > SetApplLimit(StackPtr() - STACK_MIN); >... > > >Hope this helps, >...Duane Murphy >Novell, Walnut Creek > You may want to change this to: if (StackSpace() < STACK_MIN) SetApplLimit(StackPtr() - (STACK_MIN - StackSpace())) This will make sure that you don't waste too much memory on "Large" machines. (StackSpace is a standard Toolbox trap.) Also, some development envrionments automatically call SetApplLimit as part of the normal application startup. For example, THINK Pascal calls SetApplLimit to allocate the amount of stack space you specified under your Run Options. Check your development environment documentation to see if it provides this kind of support. Cheers! John - --------------------------------------------------------------------- John Wallace buckeye@spf.trw.com +++++++++++++++++++++++++++ From: marshall@sdd.hp.com (Marshall Clow) Date: 2 Sep 92 21:40:32 GMT Organization: Hewlett Packard San Diego Printer Division In article <71922@apple.Apple.COM>, grobbins@Apple.COM (Grobbins) wrote: > [ lots of good advice deleted ] > > This is particularly an issue for faceless background apps, which have > a default stack size of only 2K. SetApplLimit will grow an FBA's stack > to at least 24K on Color QuickDraw machines, so the partition size > should be larger than that. > In writing a FBA we tracked down several cases where inits (oops, extensions) would patch a trap, and then when the trap was called, would casually throw a few Str255s on the stack, or maybe a 1K buffer. Needless to say, when an OS call used over 1K of stack space and you only have a 2K stack, you are headed for problems. Marshall Clow San Diego Printer Division Hewlett Packard Internet: marshall@sdd.hp.com AppleLink: HP.Marshall AOL: MClow +++++++++++++++++++++++++++ From: damurphy@wc.novell.com (Duane A Murphy) Date: 3 Sep 92 18:08:37 GMT Organization: Novell, Inc. - Walnut Creek In article <71922@apple.Apple.COM> grobbins@Apple.COM (Grobbins) writes: > > // Increase the space allocated for the application stack > // > // Warning: SetApplLimit always sets the stack to at least as large as the > // default stack for the machine (8K on machines with original QuickDraw, > // 24K on machines with Color QuickDraw) so the application partition > // must be large enough to accomodate an appropriate stack and heap > > OSErr IncreaseApplicationStack(Size incrementSize) > { > OSErr retCode; > > // increase the stack size by lowering the heap limit > SetApplLimit((Ptr) ((unsigned long) GetApplLimit() - incrementSize)); > retCode = MemError(); > if (retCode == noErr) MaxApplZone(); > > return retCode; > } > >Do heed the warning given in the comment. All stack allocation beyond >the default must be compensated for by increasing the partition size in >the SIZE -1 resource. > Be forwarned to test this on many machines (namely an SE or other 68000 based machine). I believe I tried this; it may have even been one of my first attempts. I think this works but is it what is desired? This increases the stack size by an amount. It does not _SET_ the stack size. I needed (as I believe the original author did) to set the stack size to a particular size. ...Duane +++++++++++++++++++++++++++ From: grobbins@Apple.COM (Grobbins) Date: 4 Sep 92 03:25:10 GMT Organization: Apple Computer Inc., Cupertino, CA In article <1992Sep3.180837.8540@novell.com> damurphy@wc.novell.com (Duane A Murphy) writes: >This increases the stack size by an amount. It does not _SET_ the stack >size. I needed (as I believe the original author did) to set the >stack size to a particular size. The original poster wanted to be guaranteed at least a 32K stack regardless of the application's partition size setting. It is not a good idea to set the stack to a specific size (although it can be done by setting ApplLimit to CurStackBase minus the desired size) because the System may decide to make demands of your stack beyond the normal default. It can do so safely by just upping the default stack and partition sizes when launching. This happened with the introduction of Color QuickDraw. Additional stack space was necessary for safe QuickDraw use, so the default stack size was upped to 24K and the partition size of each application was increased upon launch to accomodate the larger stack. Any application which sets a specific stack size after launching defeats the ability of System software to increase the stack. At the time the program is written, 16K may be plenty large for the stack, but that may not be true for the same program under some future version of System software. For this reason, DTS has for some time advocated that the stack be increased when necessary (by lowering ApplLimit), but not fixed to a specific size. Grobbins grobbins@apple.com Usual disclaimers apply. +++++++++++++++++++++++++++ From: phils@chaos.cs.brandeis.edu (Phil Shapiro) Date: 4 Sep 92 14:03:50 GMT Organization: Symantec Corp. >>>>> On Wed, 2 Sep 92 20:23:29 GMT, buckeye@spf.trw.com (John Wallace) said: > if (StackSpace() < STACK_MIN) > SetApplLimit(StackPtr() - (STACK_MIN - StackSpace())) > This will make sure that you don't waste too much memory on "Large" > machines. (StackSpace is a standard Toolbox trap.) This is the best solution, but... On 68000 machines, the trap StackSpace() returns garbage unless you've already called MaxApplZone() (in which case the call to SetApplLimit will fail). I'm not sure, but this may have been fixed in System 7. In any event, I would recommend using the low memory global DefltStack instead. In THINK C, you can just write: SetApplLimit(GetApplLimit() - (STACK_NEEDED - DefltStack)); In MPW C, you'd use: SetApplLimit(GetApplLimit() - (STACK_NEEDED - *((long *)DefltStack))); In Pascal, you'd use: SetApplLimit(GetApplLimit - (STACK_NEEDED - LongPtr(DefltStack)^)); Is this in the FAQ? -phil - -- Phil Shapiro Software Engineer Language Products Group Symantec Corporation Internet: phils@cs.brandeis.edu +++++++++++++++++++++++++++ From: damurphy@wc.novell.com (Duane A Murphy) Date: 4 Sep 92 16:00:59 GMT Organization: Novell, Inc. - Walnut Creek In article phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: >>>>>> On Wed, 2 Sep 92 20:23:29 GMT, buckeye@spf.trw.com (John Wallace) said: > > > if (StackSpace() < STACK_MIN) > > SetApplLimit(StackPtr() - (STACK_MIN - StackSpace())) > > > This will make sure that you don't waste too much memory on "Large" > > machines. (StackSpace is a standard Toolbox trap.) > >This is the best solution, but... On 68000 machines, the trap >StackSpace() returns garbage unless you've already called >MaxApplZone() (in which case the call to SetApplLimit will fail). I'm >not sure, but this may have been fixed in System 7. > >In any event, I would recommend using the low memory global DefltStack >instead. In THINK C, you can just write: > > SetApplLimit(GetApplLimit() - (STACK_NEEDED - DefltStack)); ... Thank you for jogging my memory. This is the problem that I ran into. Once MaxApplZone is called adjusting the stack space larger will cross into the heap space simulating a stack heap collision. That is why it was necassary to adjust the stack size at the start as opposed to dynamically at run time. (I think this sounds rights). How can one adjust the stack size dynamically (as recommended by DTS) when it simulates moving the stack into the heap? No it is not fixed on System 7. In fact StackSpace() works differently on different models with the _SAME_ system! This was very confusing. ...Duane +++++++++++++++++++++++++++ From: ksand@apple.com (Kent Sandvik) Date: 5 Sep 92 21:03:26 GMT Organization: Apple In article , marshall@sdd.hp.com (Marshall Clow) wrote: > In article <71922@apple.Apple.COM>, grobbins@Apple.COM (Grobbins) wrote: > > [ lots of good advice deleted ] > > > > This is particularly an issue for faceless background apps, which have > > a default stack size of only 2K. SetApplLimit will grow an FBA's stack > > to at least 24K on Color QuickDraw machines, so the partition size > > should be larger than that. > > > > In writing a FBA we tracked down several cases where inits (oops, > extensions) would patch a trap, and then when the trap was called, would > casually throw a few Str255s on the stack, or maybe a 1K buffer. > > Needless to say, when an OS call used over 1K of stack space and you only > have a 2K stack, you are headed for problems. Another hint, check out what MoveHHi is doing with the stack. I'm not telling it :-). Kent Sandvik/DTS +++++++++++++++++++++++++++ From: chuckp@u.washington.edu (Chuck Pliske) Date: 9 Sep 92 05:24:09 GMT Organization: University of Washington In article <1992Sep4.160059.29329@novell.com> Duane A Murphy, damurphy@wc.novell.com writes: >>In any event, I would recommend using the low memory global DefltStack I wrote an extension "Stack6000", useful for the 68000 machines because Apple sets the default stack to about $4800 in the Plus, SE and PB100, and $6000 on the other machines. I simply set DefltStack to $6000 (if needed) and exit. Subsequent programs using the default all get the new value. So far, it has worked fine. (Available on Sumex) Chuck --------------------------- End of C.S.M.P. Digest **********************